FIG. 1 shows a typical apparatus 100 for processing documents containing structured data expressed using the Extensible Markup Language (XML). The apparatus 100 includes an Extensible Stylesheet Language (XSL) processor 102 that translates an XML document 104 into a transformed document 106. The transformed document 106 can comprise another XML document, or a document expressed in a presentation-oriented markup language, such as Hypertext Markup Language (HTML). XML provides tags that represent the subject matter contained in a document. In contrast, presentation-oriented languages, such as Hypertext Markup Language (HTML), provide tags that convey the visual appearance of a document. Accordingly, these technologies complement each other; XML allows information to be efficiently transferred and processed, while HTML allows information to be presented for display.
XSLT itself uses the syntax of XML. The XSLT processor 102 performs its translation function by making reference to one or more style sheets 108. The style sheets 108 contain a collection of rules for transforming elements in the input XML document 104 into the transformed document 106. To perform this function, XSLT relies heavily on XPath functionality. XPath is a general-purpose query notation for addressing and filtering the elements and text of XML documents. XPath expressions can address parts of an XML document, and can manipulate strings, numbers, and Booleans, etc. In the context of the XSLT processor 102, XPath expressions can be used to find a portion of the XML document 104 that matches a prescribed match pattern, and then perform some translation operation on that portion using a rule provided in the style sheets 108. XML, XSL, and XPath are described at length in their governing specifications provided by the World Wide Web Consortium (W3C).
The translation function provided by the XSLT processor 102 is strictly one-way. In other words, the XSLT processor 102 efficiently translates the structured data in the XML document 104 into the transformed document 106. But conventional XSLT does not also provide a mechanism for translating the transformed document 106 back into the XML document 104 from which it is derived. More specifically, it can generally be said that a collection of elements in the transformed document 106 are derived from or based on one or more elements in the XML document 104; however, there is generally no way of discovering this nexus once the XML document 104 has been translated into the transformed document 106. This situation is akin to the scenario in which a file is containing source code expressed in human readable form is transformed into executable code using a compiler. It may be impossible to determine the source code simply by examining the resultant executable code. The one-way nature of the translation of the XML document 104 into the transformed document 106 is represented in FIG. 1 by the arrow 110.
The one-way nature of the translation 110 performed by the XSLT processor 102 introduces difficulties in applications that demand two-way interaction between the XML document 104 and the transformed document 106. For instance, an HTML document may include a collection of fields for receiving data entered by an editing user. If this HTML document is based on an underlying XML document, it would be desirable to provide a mechanism for routing the user's input back to the source XML document. As explained above, bare XSLT does not provide the intelligence to provide this functionality.
As such, there is an exemplary need in the art for a data processing application that provides mapping between structured data and a visual surface used to display the structured data.